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PREFACE 


Information  scientists  at  RAND  have  had  a  continuing  interest  in  the  design  and 
appropriate  use  of  electronic  mail  systems.  During  the  past  decade,  this  interest  has 
manifested  itself  in  the  design  of  the  MH  electronic  mail  system,  widely  distributed  in  many 
releases  of  the  UNIX  operating  system.  The  original  user’s  manual  for  MH  was  B.  S. 
Borden,  R.  S.  Gaines,  and  N.  Z.  Shapiro’s  The  MH  Message  Handling  System:  User’s 
Manual,  The  RAND  Corporation,  R-2367-AF,  November  1979;  guidelines  for  use  of 
electronic  mail  systems  were  proposed  in  N.  Z.  Shapiro  and  R.  H.  Anderson’s  Toward  an 
Ethics  and  Etiquette  for  Electronic  Mail,  The  RAND  Corporation,  R-3283-NSF/RC,  July 
1985.  Many  MH  users  have  exploited  its  power  and  adaptability  without  fully  realizing  the 
underlying  source  of  that  power.  To  date,  the  observations  and  principles  underlying  the 
design  of  MH  have  not  been  documented.  This  Note’s  puipose  is  to  rectify  that  omission. 

The  authors  think  the  design  principles  embodied  in  MH  remain  highly  relevant  and 
important  for  interactive  information  systems,  yet  many  major  systems — including  recently 
developed  electronic  mail  or  “office  information”  systems — do  not  follow  these  principles 
(to  their  detriment,  the  authors  believe).  This  Note  should  be  of  interest  to  designers, 
selectors,  and  users  of  interactive  computer  systems. 
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SUMMARY 


The  MH  electronic  mail  (e-mail)  system,  which  has  been  in  use  throughout  The 
RAND  Corporation  for  more  than  nine  years,  is  the  result  of  the  conscientious  application  of 
certain  design  principles — principles  we  believe  expedite  computer-supported  cooperative 
work  within  work  groups. 

The  design  principles  of  MH  derive  from  our  observation  that  a  user’s  activities  with 
e-mail  have  much  in  common  with  other  information  manipulation  activities  the  user 
performs  with  a  computer.  As  a  result,  the  user-computer  interface  to  information-handling 
functions  should  be  the  same,  whether  or  not  it  is  used  for  working  on  e-mail.  In  addition, 
the  same  underlying  processes  and  tools  should  be  as  available  to  an  e-mail  system  as  they 
are  to  other  applications  within  a  computer  system. 

We  find  the  UNIX1  shell  (that  is,  the  command  interpreter  for  this  operating  system) 
and  its  utilities  to  be  an  example  of  a  system  particularly  well  suited  to  carry  out  this  design 
philosophy,  although  the  design  principles  are  certainly  not  restricted  to  UNIX.  For  example, 
MH  has  been  ported  to  the  MS-DOS  operating  system.  The  commands  comprising  the  MH 
e-mail  system  are  individual  commands  at  the  operating  system  level,  and  each  MH  message 
is  a  normal  text  file.  These  design  decisions  allow  (for  example)  use  of  the  standard  file 
system  to  create  a  hierarchy  of  mail  file  folders,  use  of  any  text  editor  available  within  the 
system  to  create  a  message  or  incorporate  information  into  a  message,  and  use  of  all  normal 
operating  system  commands,  such  as  print  or  search,  on  MH  messages. 

Additions  have  been  made  to  the  basic  MH  system  to  make  it  more  effective  within 
RAND’s  organizational  environment.  These  additions,  called  RANDMail,  include: 

•  A  corporatewide  database  containing  several  attributes  for  each  employee, 
including  whether  the  employee  prefers  to  receive  e-mail  in  electronic  or  hard¬ 
copy  form  (or  both); 

•  A  new  command,  name,  providing  access  to  the  database  at  the  operating 
system  command  level; 

•  The  ability  to  use  any  fragment  of  a  person’s  name  as  an  identifier  in  a  message 
header,  with  that  fragment  matched  against  the  database  to  obtain  the  complete 

’UNIX  is  a  registered  trademark  of  AT&T  Bell  Laboratories. 


-  VI  - 


e-mail  address  (if  the  fragment  is  ambiguous,  the  ambiguity  is  displayed  to  the 
user  for  further  clarification);  and 

•  Automatic  printing  and  routing,  within  corporate  internal  mail  delivery,  of 
messages  to  be  delivered  in  hard-copy  form. 

Some  e-mail  systems  tend  to  empower  the  user  as  sender,  some  empower  the  user  as 
receiver.  We  believe  that  the  MH  system,  although  providing  considerable  flexibility  and 
power  to  the  user  in  both  these  roles,  particularly  empowers  the  user  as  a  processor  of 
information  exchanged  electronically  within  work  groups.  The  design  bias  of  MH  can  be 
summarized  as  "all  power  to  the  user,”  with  both  the  costs  and  advantages  that  maxim 
entails. 

In  use  in  thousands  of  institutions  worldwide,  MH  is  distributed  as  part  of  many 
standard  releases  of  the  UNIX  operating  system.  It  is  in  the  public  domain. 
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I.  INTRODUCTION 


Electronic  mail  (e-mail)  will  probably  be  an  important  component  of  any  well- 
designed  system  for  computer-supported  cooperative  work  (CSCW).  This  proposition  is 
evidenced  by  the  many  commercial  and  experimental  systems  for  CSCW  that  have  appeared 
over  the  years;  in  almost  all  cases,  users  have  used  them  for  electronic  mail,  sometimes  by 
stretching  and  distorting  the  designers’  intentions  (Shapiro  and  Anderson,  1985). 

This  Note  describes  one  e-mail  system,  MH,  in  use  throughout  The  RAND 
Corporation  for  more  than  nine  years.  It  is  now  in  the  public  domain  and  used  by  thousands 
of  other  organizations.  We  present  the  principles  and  assumptions  underlying  MH’s  design, 
key  architectural  features  that  make  MH  effective  for  supporting  cooperative  work,  and 
examples  of  features  that  have  proved  especially  useful  in  our  own  corporate  environment. 

An  electronic  mail  system:  (1)  permits  the  asynchronous  electronic  interchange  of 
information  between  persons,  groups  of  persons,  and  functional  units  of  an  organization;  and 
(2)  provides  the  mechanisms  supporting  the  creation,  distribution,  consumption,  processing, 
and  storage  of  this  information.  Some — but  not  necessarily  all — of  this  information  will  be 
structured.  We  emphasize  its  potentially  unstructured  aspect  because  we  believe  an  essential 
attribute  of  e-mail  (in  addition  to  its  asynchronicity)  must  be  flexibility. 

Finally,  in  our  view,  a  highly  desirable  attribute  of  electronic  mail — although  not  part 
of  its  essential  nature — is  heterogeneity.  To  be  capable  of  evolutionary  growth,  systems 
should  not  require  that  identical,  homogeneous  computer  hardware  or  software  be  used  by 
all  participants.  This  freedom  is  especially  important  for  systems  that  span  organizations  or 
organizational  boundaries.  Heterogeneity  is  particularly  critical  for  the  long-term  goal  of 
integrating  the  work  of  many  people,  where  each  person  uses  his  or  her  own  favorite 
applications  and  is  likely  to  be  a  member  of  multiple  groups  (Bikson,  Gutek,  and  Mankin, 
1987).  In  this  environment,  highly  specific  CSCW  applications  may  not  be  desirable.  We 
contend  that  examining  which  features  of  relatively  generic  systems  make  them  suitable  for 
supporting  cooperative  work  among  members  of  potentially  diverse  system  environments  is 
important.  We  examine  the  design  of  MH  as  an  example  of  a  good  tool  for  collaboration  in 
view  of  its  flexibility,  heterogeneity,  and  power  for  the  user. 
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II.  SOME  OBSERVATIONS  ABOUT  ELECTRONIC  MAIL 


The  architecture  of  MH  was  derived  from  basic  observations  about  the  nature  of 
electronic  mail.  First,  using  electronic  mail  has  much  in  common  with  other  activities  the 
user  performs  with  a  computer.  The  difference  is  that  e-mail  is  a  mechanism  for  dealing 
with  the  rest  of  the  world,  whereas  most  computer  interfaces  primarily  involve 
communication  between  the  user  and  programs  within  his  or  her  own  computer(s).  This 
distinction  is  minor  because  it  chiefly  involves  just  wrapping  an  “envelope”  around  whatever 
other  information  activities  the  user  has  performed  (see  Talbert,  Bikson,  and  Shapiro,  1984). 

Second,  a  generic  set  of  information  manipulation  operations  exists,  such  as 
composition,  storage,  retrieval,  and  copying.  Although  we  cannot  specify  here  exactly  what 
this  set  should  be,  we  are  certain  that  all  the  same  operations  also  apply  to  electronic  mail. 

From  these  two  general  observations,  we  derive  three  design  implications.  First,  the 
user-computer  interface  to  information  manipulation  functions  should  be  the  same  whether 
or  not  the  user  is  working  on  e-mail.  Adhering  to  this  design  principle  creates  an  important 
benefit  If  the  same  user  interface  tools  are  used  for  e-mail  as  for  other  information 
manipulation  functions,  then  improvements  to  the  interface  (for  example,  providing  graphic 
or  windowing  options)  can  automatically  enhance  the  e-mail  system  as  they  become 
available.  For  example,  as  windowing  environments  such  as  SunView1  have  become 
available  for  UNIX,2  we  have  routinely  used  those  features  as  an  “enhancement”  to  MH  by 
using  one  window  for  an  overview  scan  listing  of  message  headers,  another  for  message 
composition,  and  a  third  for  alerting  the  user  that  new  mail  has  been  received.  The  move  to 
a  windowing  environment  provided  considerably  more  power  to  the  user  in  controlling 
simultaneous  message  system  processes,  but  entailed  no  changes  at  all  to  the  MH  system 
itself.  Other  examples  of  our  experience  with  this  form  of  “automatic”  improvement  are 
described  below. 

Second,  the  processes  used  to  perform  information  manipulation  tasks  should  be  the 
same  whether  or  not  the  user  is  working  on  e-mail.  For  example,  printer  access,  privacy 
control,  priority  assignment,  accounting  and  the  like  should  all  use  the  same  underlying 
computer  processes. 

'SunView  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 

2UNIX  is  a  registered  trademark  of  AT&T  Bell  Laboratories. 
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Third,  a  user’s  work  life  involves  synthesis  across  various  specific  applications. 
Accessing  a  calendar,  creating  or  retrieving  bibliographic  references,  using  a  spreadsheet  or 
word  processor  or  Rolodex-type  program,  updating  or  using  a  corporatewide  database,  using 
a  decision-support  system,  or  sending  a  message  containing  fragments  of  information  from 
these  other  activities — all  these  activities  are  not  self-contained  separate  islands.  Even  if 
such  activities  are  physically  separate  processes  within  a  computer,  they  should  appear  to  the 
user  as  a  consistent  set  of  information  manipulation  tools. 

The  main  conclusion  we  have  drawn  for  e-mail  design  is  that  it  should  not  be  an 
encapsulated,  self-contained  system  providing  its  own  interfaces  and  information-handling 
processes.  Instead,  to  whatever  extent  possible,  it  should  use  existing  resources  for  generic 
operations. 
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III.  MH  DESIGN  AND  RANDMAIL  ENHANCEMENTS 


MH  DESIGN 

The  UNIX-based1  e-mail  system  MH  was  developed  in  1978  at  RAND.2  The  design 
of  MH  tries  to  embody  the  implications  outlined  above  through  two  main  design  decisions: 


•  MH  commands — the  primitive  operations  on  a  message — are  UNIX  shell 
commands;  and 

•  Each  MH  message  is  a  normal  UNIX  file. 


From  these  decisions,  it  follows  that  collections  of  related  messages  may  be  placed 
into  UNIX  directories,  which  MH  calls  folde.s,  as  can  folders  of  folders  and  so  on  because 
of  UNIX’s  hierarchical  file  system.  All  normal  UNIX  file  and  directory  operations  are 
therefore  available  for  use  on  MH  messages.  A  file  is  the  unit  of  information  this  operating 
system  can  handle.  By  making  a  message  a  file,  then,  we  gain  the  power  of  the  operating 
system  on  the  essential  unit  of  information  in  an  e-mail  system,  a  message.  For  space  and 
operating  efficiency,  some  e-mail  systems  use  a  file  to  store  a  collection  of  messages;  MH 
sacrifices  some  of  this  efficiency  for  the  advantages  of  the  file  =  message  equation. 

Because  of  these  design  principles,  users  can,  for  example,  specify  (either  in  a  profile 
of  defaults,  or  at  the  time  of  message  creation)  a  favorite  text  editor  be  used  for  message 
composition;  the  same  editor  used  for  creating  other  files  is  invoked  for  creating  messages. 
Within  the  “e”  editor  commonly  in  use  at  RAND,  any  UNIX  program  or  filter  can  be 
invoked  with  its  (standard  output)  results  inserted  at  the  cursor’s  current  location  in  a  file. 
Thus,  all  the  power  of  UNIX  and  its  applications  is  directly  available  during  the  composition 
of  a  message  and  all  user-supplied  parts  of  its  header.  Users  often  concatenate  a  file  into  the 


•The  following  description  of  MH  design  features  uses  UNIX  terminology  for 
consistency  and  because  of  MH’s  historical  roots.  However,  these  same  design  principles 
apply  to  the  design  of  electronic  mail  systems  within  other  operating  systems  having  some  of 
the  modularity  and  flexibility  of  UNIX. 

^he  MH  design  was  conceived  by  Norm  Shapiro  and  Stockton  Gaines  at  RAND 
circa  1977.  The  first  version  was  implemented  by  Bruce  Borden  in  three  weeks  under 
UNIX  version  6  in  late  1978,  and  was  in  RANDwide  use  within  six  months.  In  1982,  under 
the  leadership  of  Marshall  Rose  at  the  University  of  California,  Irvine,  MH  began  a  five- 
year  series  of  metamorphoses.  RANDmail  enhancements  were  added  at  RAND  in  February 
1984. 
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body  of  a  message;  or,  within  a  reply,  they  may  cut  and  paste  portions  of  the  message  being 
answered.  As  more  powerful  word  processors  such  as  WordPerfect  become  available  under 
UNIX,  all  their  features  similarly  become  available  for  message  composition,  editing,  and  so 
on  under  MH. 

MH  ENHANCEMENT 

Use  of  the  basic  MH  system  became  increasingly  problematic  as  it  expanded.  As  it 
escaped  the  confines  of  the  initial  user  groups  and  spread  more  broadly,  we  learned  that  not 
all  users 

•  Had  easy  access  to  terminals  or  personal  computers;  even  those  who  did  might 
prefer  to  receive  e-mail  messages  in  hard-copy  form  (either  in  addition  to,  or  in 
place  of,  an  electronic  version); 

•  Knew  the  terminal  access  capabilities  or  media  preferences  of  all  other  users; 

•  Resided  on  the  same  machine  or  file  server, 

•  Knew  all  other  users’  log-in  names  or  host  machines  so  messages  would  be 
correctly  addressed. 

For  these  reasons,  we  enhanced  MH  with  a  system — RANDMail — tailored  to 
RAND’s  organizational  needs.3  RANDMail  is  based  on  the  theory  that  when  you  want  to 
communicate  with  a  person,  the  way  you  address  that  person  should  be  independent  of  the 
communication’s  modality.  That  is,  you  should  be  able  to  look  up  someone’s  room  number 
or  telephone  number,  or  give  the  name  in  the  ‘To:”  line  of  a  message,  in  the  same  way. 
Furthermore,  all  reasonable  descriptors  of  a  person  (for  example,  initials,  nicknames, 
portions  of  a  name)  should  be  valid  electronic  mail  addresses,  just  as  they  usually  are  in 
internal  paper  mail.  To  know  log-in  names,  machine  locations,  or  routes  should  not  be 
necessary.  In  short,  the  system  should  be  adaptable  to  the  way  groups  work  (Bikson,  1987). 

3MH  now  runs  under  MS-DOS  and  a  variety  of  UNIX  versions  and  computer 
architectures;  it  is  in  use  at  several  thousand  s.;es.  Organizations  contributing  heavily  to  MH 
include  RAND;  the  University  of  California,  Irvine;  the  University  of  California,  Berkeley; 
and  Northrop.  Individual  contributors  included  Diane  Alexander,  Robert  Anderson,  Cliff 
Bamford,  Donna  Betancourt,  Tora  Bikson,  Bruce  Borden,  David  Crocker, Terry  Domae, 
Stockton  Gaines,  Van  Jacobson,  Phyllis  Kantar,  Mark  LaCasse,  John  Romine,  Marshall 
Rose,  Norm  Shapiro,  Einar  Stefferud,  Jerry  Sweet,  Lee  Talbert,  and  Terry  West.  Tlr 
program  is  in  the  public  domain. 
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To  implement  this  premise,  we  made  four  additions  to  MH.  First,  we  created  a  single 
corporatewide  database,  which  all  RAND  computers  could  access,  containing  for  each 
company  employee  or  consultant  information  fields  such  as  name  (plus  nickname,  if  any), 
extension,  department,  mail  stop,  log-in  name,  home  computer,  and  message  routing  (that  is, 
whether  the  message  was  to  be  sent  hard  copy  or  soft  copy,  or  both). 

Second,  we  created  a  new  UNIX  command,  name,  to  access  this  database.  Followed 
by  any  unambiguous  abbreviation  of  a  person’s  full  name,  the  name  command  generates  a 
listing  of  the  entire  database  entry  for  that  person.  A  name  command  followed  by 
fragmentary  information  (that  is,  ambiguous  within  the  database)  results  in  an  overview 
“scan”  listing  showing  summary  information  for  all  individuals  in  the  database  meeting  the 
criteria.  For  example,  name  RA  results  in  the  display  of  several  names  (Ruth  Almond, 

Robert  H.  Anderson,  Rae  Archibald)  satisfying  that  pattern. 

Third,  anywhere  a  recipient’s  name  can  appear  within  a  message  header  (for 
example,  in  the  ‘To:,”  “cc:,”  or  “bcc:”  fields),  giving  an  identifier  that  uniquely  identifies  the 
individual  within  the  database  in  the  same  form  as  an  argument  to  the  name  command  is 
sufficient.  A  message  header,  for  instance,  might  be  composed  as  ‘To:  RHA,  PKantar, 
NShap.” 

The  system  would  expand  this  header  into  complete  proper  names  (with  computer 
addresses)  by  referring  to  the  database  at  the  time  the  message  was  sent.  If  any  abbreviated 
name  is  ambiguous,  the  user  receives  a  listing  such  as  the  one  described  above,  with  the 
option  to  re-edit  the  message  to  correct  the  ambiguity. 

Fourth,  everyone  in  the  organization  can  receive  an  electronic  message,  regardless  of 
terminal/workstation  access.  Messages  addressed  to  users  who  need  orpreic.  hard  copies 
are  automatically  routed  to  a  printer  and  are  delivered  in  the  next  internal  mail  distribution. 

By  itself,  each  of  these  features  is  straightforward.  Together,  they  mean  something 
very  important:  Every  message  is  routed  to  a  person.  As  a  person  changes  rooms, 
departments,  host  computers,  name  (for  example,  from  maiden  to  married)  and  the  like,  a 
single  update  to  a  master  database  assures  that  the  person  gets  the  message.  Significantly, 
the  same  corporate  database  is  used  to  print  the  corporate  telephone  directory;  it  is  also  used 
by  RAND  telephone  operators  to  route  calls  to  primary  or  auxiliary  telephone  extensions. 

As  a  central  corporate  data  facility,  its  chances  for  accuracy  and  timeliness  are  greatly 
increased.  And  although  we  call  the  enhanced  system  RANDMail,  we  think  its  generic 
features  are  not  unique  to  RAND.  Any  organization  striving  for  computer-supported 
cooperative  work  would  do  well  to  create  an  on-line  database  about  people  and  their 
preferences  to  facilitate  the  exchange  of  electronically  captured  information. 
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IV.  RANDMAIL  FOR  COMPUTER-SUPPORTED  COOPERATIVE  WORK 


We  have  suggested  that  combining  the  power  of  UNIX  with  RANDMail  primitives 
as  described  above  will  support  a  variety  of  needs  related  to  computer-supported  cooperative 
work.  Below,  we  show  how  MH  facilities  compare  with  oth°r  approaches  to  satisfying 
those  needs.  For  convenience,  we  have  grouped  the  facilities  as  (1)  the  user  as  sender,  (2) 
the  user  as  receiver,  and  (3)  the  user  as  mail  processor. 

THE  USER  AS  SENDER 

A  main  strength  of  The  Coordinator1  (Winograd  and  Flores,  1986;  Flores,  1982)  is 
the  power  it  gives  the  message’s  sender.  He  or  she  can  determine  the  type  of  message  (for 
example,  whether  it  is  part  of  a  conversation  for  action  or  for  possibilities),  which  in  turn 
determines  the  type  of  follow-up  processing  performed  in  both  the  sender’s  and  the 
recipient’s  systems. 

In  attempting  to  provide  similar  power  to  the  “user  as  sender,”  MH  would  rely  on 
users’  capabilities  to  tailor  their  messaging  environment  (for  example,  in  the  mail  profile). 
For  instance,  a  user  may  want  to  tailor  the  message  system  to  facilitate  a  common  group 
operation,  such  as  establishing  a  milestone  task  to  be  completed  by  a  certain  date;  one 
method  in  MH  is  to  add  certain  fields  to  a  standard  message  form,  such  as  “Msg-type:  task” 
and  “Completion-date:.”  The  user’s  .login  file  could  then  contain  a  standard  command  to  be 
issued  upon  each  log-in,  such  as  check-completions.  This  command  file  could  test  all 
messages  of  type  “task”  in  the  user’s  current  folder,  for  instance,  and  give  notice  of 
completion  dates  earlier  than  the  day’s  date  for  which  no  corresponding  reply  had  been 
received. 

THE  USER  AS  RECEIVER 

In  contrast,  the  information  lens  model  (Malone  et  al.,  April  1987  and  May  1987) 
seems  to  emphasize  facilities  for  the  user  as  message  receiver.  In  MH,  similar  kinds  of 
power  to  the  user  as  receiver  would  also  be  provided  through  shell  files.  Perhaps  the  best 
example  of  this  is  what  we  have  come  to  call  “message  triaging.”  A  UNIX  shell  file  of 
commands  is  created  that  performs  MH  pick  operations  to  identify  incoming  messages,  for 


'The  Coordinator  is  a  registered  trademark  of  Action  Technologies,  Inc. 


-8- 


example,  as  being  from  certain  correspondents,  or  having  certain  keywords  in  their  subject 
lines,  or  coming  from  a  certain  institution.  These  messages  are  automatically  identified 
using  standard  features  of  pick;  the  messages  may  then  be  refiled  from  the  MH  in-box  to 
other  mail  folders.  As  time  permits,  the  user  may  then  look  through  folders  labeled 
“urgent,”  “routine,”  or  perhaps  having  the  names  of  specific  projects  on  which  the  user 
works.  Such  processing  of  received  messages  may  be  quite  independent  of  any  knowledge 
or  cooperation  by  the  sender(s).  For  instance,  if  “Dave  L.”  is  your  boss,  you  may  send  all 
messages  from  him  automatically  to  the  “urgent”  folder.  Of  course,  the  triaging  of  incoming 
messages  is  facilitated  if  senders  within  a  work  group  observe  some  standard  protocols,  such 
as  using  specific  project  words  in  the  subject  line  to  indicate  message  content.  But  to  assure 
power  over  the  handling  of  incoming  messages  independent  of  sender  involvement,  MH 
avoids  rigid  subject-line  requirements. 

THE  USER  AS  MAIL  PROCESSOR 

If  MH  has  an  emphasis,  it  is  probably  on  providing  facilities  to  users  as  general 
processors  of  mail.  This  orientation  accords  well  with  work  structures  at  RAND,  where 
individuals  typically  belong  to  multiple  work  groups;  groups  form  and  reform  relatively 
quickly;  and  individuals  are  quite  likely  to  be  a  leader  of  one  work  group  and  a  subordinate 
in  another.  A  sampler  of  MH  practices  illustrating  this  orientation  in  the  RAND 
environment  follows. 

Suppose,  for  instance,  your  group  wants  to  code  certain  messages  as  belonging  to  a 
category  (for  example,  related  to  the  keyword  proposal),  so  they  can  be  stored,  located,  or 
referenced  together.  The  easy  way  to  do  this  is  to  agree  within  the  group  always  to  use  a 
keyword  or  phrase  such  as  proposal  within  the  subject  line.  Then  the  MH  pick  command 
can  be  used  to  access  all  such  messages  in  your  electronic  in-box  as  follows: 

%  pick  -subject  proposal 

To  pick  all  such  proposal-relevant  messages  since  last  Friday  and  refile  them  into  a 
folder  called  “prop”  while  obtaining  a  scan  listing  of  the  messages  selected,  you  could  issue 
these  two  commands: 

%  refile  +prop  'pick  -subject  proposal  -after  friday' 

%  scan  +prop 

The  pick  command  extracts  the  requested  messages  and  returns  a  “message 
sequence,”  or  list  of  the  message  numbers  satisfying  the  request.  That  message  sequence 
becomes  an  input  parameter  to  the  refile  command,  which  files  them  in  the  folder  (a  normal 
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UNIX  subdirectory)  prop.  A  scan  command  for  the  prop  folder  then  produces  a  “scan 
listing”  with  one  line  per  message,  giving  an  overview  of  the  folder’s  contents.  The 
connectives  -and,  -or,  -not  along  with  braces  can  be  used  with  the  pick  command  to  create 
Boolean  conditions.  In  addition,  a  regular  expression  of  the  form  used  by  l 'NIX’s  grep 
command  can  be  used  to  indicate  the  string  to  be  searched  for  within  a  field — or  anywhere 
within  the  message. 

Rather  than  having  everyone  within  a  work  group  remember  to  use  a  keyword  within 
the  subject  line  of  a  message,  creating  prepared  forms  for  messages  is  often  easier,  these 
forms  can  have  additional  fields  built  into  their  headers,  which  pick  can  access.  For 
example,  in  composing  a  message,  the  user  can  issue  a  “form”  flag  telling  which  UNIX  text 
file  to  use  as  the  beginning  “message  form”: 

%  comp  -form  propgroup 

The  UNIX  propgroup  file  might  have  a  prebuilt  message  header  containing 
additional  fields,  such  as  “Keyword:  proposal.”  Anyone  using  this  form  could  then  pick  all 
proposal-related  messages  from  the  current  folder  by  issuing  the  pick  command: 

%  pick  -  -Keyword  proposal 

The  double  dash  here  indicates  a  search  for  a  nonstandard  field  name  within  the 
header,  followed  by  any  regular  expression  indicating  a  search  string  in  that  field.  The 
prepared  message  form  might  also  have  a  prebuilt  “cc:”  line,  if  a  standard  routing  list  for 
these  messages  exists. 

Note  that  the  group-customized  message  header,  plus  unlimited  room  for  the  message 
body,  is  just  a  standard  UNIX  text  file  that  comes  up  within  a  text  editor  window.  The 
header’s  contents  may  be  revised  at  any  time  during  the  composition  of  a  message,  a 
“surprisingly  useful”  feature  (apologies  to  Malone  et  al„  April  1987)  because  changing  one’s 
mind  about  the  distribution  list,  subject  line,  and  so  on  as  a  message  takes  shape  is  easy. 
Further,  UNIX  command  (shell)  file  features  can  be  used  to  abbreviate  frequently  used 
combinations  of  message  commands,  so  that  commonly  used  sequences  can  be  invoked  by  a 
simple  identifier. 

Many  other  examples  of  flexibility  empowering  the  generic  mail  user  in  MH  could  be 
given.  Those  provided  here  were  chosen  in  an  attempt  to  give  concrete  illustrations  of  the 
design  principles  that  engendered  them.  A  quantitative  study  of  the  spread  of  the 
RANDMail  system  throughout  RAND,  showing  patterns  of  communication  and  many  other 
aspects  of  its  use,  is  contained  in  Bikson  (1987)  and  Eveland  and  Bikson  (1987)  A 
description  of  users’  experience  with  MH  and  other  electronic  mail  systems  and  resulting 
user  guidelines  is  available  in  Shapiro  and  Anderson  (1985). 
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V.  CONCLUSIONS 


To  date,  the  design  and  use  of  MH  and  its  RANDMail  extensions  have  been  guided 
by  several  principles: 

•  What  people  do  when  handling  electronic  mail  is  mainly  what  they  do  anyway: 
create  files,  edit  text,  group  related  information  in  directories,  search  for 
information,  and  delete  files.  An  electronic  mail  system  should  build  upon 
existing  tools  for  these  tasks — tools  that  are  known  and  comfortable  to  the 
users. 

•  Messages  are  for  people.  The  same  names,  nicknames,  and  common 
references  used  in  other  media  should  be  valid  in  addressing  electronic 
messages. 

•  “All  power  to  the  user,”  whether  as  sender,  receiver,  or  processor,  is  a  good 
design  maxim.  Rather  than  providing  a  fixed  message  header,  or  fixed  types  of 
message  forms,  a  system  should  allow  users  to  create  the  message  header  fields 
they  need  and  then  perform  the  desired  processes  on  these  fields  and  their 
contents. 

•  The  totality  of  a  message,  including  any  user-specifiable  portions  of  its  header, 
should  be  changeable  by  the  user  at  any  time  during  message  creation  or 
editing.  The  development  of  the  header  and  the  message  body  are  interrelated 
acts  and  should  be  treated  as  one  conceptual  unit. 

•  Achieving  mail  system  functionality  at  the  expense  of  flexibility  and 
heterogeneity  is  not  necessary.  A  generic  mail  system  can  be  accommodated 
and  tuned  to  support  a  specific  work-group  environment,  as  we  have 
demonstrated  by  wedding  the  features  of  UNIX  and  MH  primitives. 

Electronic  mail  systems,  as  everything  else,  have  trade-offs.  With  MH  or  other 
systems  designed  according  to  the  principles  we  have  suggested,  generic  functionality  and 
certain  simple  defaults  are  immediately  available  to  all  users.  To  attain  more  substantial 
advantages  and  to  take  full  advantage  of  providing  “all  power  to  the  user,”  users  must  be 
able  to  invest  time  and  effort  in  learning  about  the  system  and  in  developing  their 
communication  environments.  The  bad  news  is  that  when  the  effort  is  not  made,  work 
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groups  do  not  end  up  with  a  system  customized  to  fit  their  work  environments;  the  good 
news  is  the  adaptability.  If  your  project  team  changes  tomorrow,  you  can  change  your  mail 
environment  accordingly;  if  you  want  to  change  the  “cc:”  line  the  minute  you  change  your 
mind  about  who  should  be  copied,  you  can — and  so  on.  MH  implements  the  “all  power  to 
the  user”  philosophy  we  find  in  UNIX,  with  the  work-group  costs  and  advantages  that 
maxim  entails. 
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